Walk any automation trade show floor this year and you’ll hear the same phrase from booth after booth: Secure by Design. It’s on PLC vendor slide decks, HMI software one-pagers, SCADA platform datasheets. CISA’s Secure by Design pledge has become the OT industry’s version of a sustainability statement — something every vendor signs, few plants verify, and almost nobody ties to an actual purchase decision.
That’s a mistake, and it’s an expensive one to keep making right now, because a lot of plants are hitting control system renewal and greenfield procurement cycles at exactly the moment these pledges are maturing from press-release language into something with real substance behind it. If you’re writing an RFP for a new HMI platform or renegotiating a SCADA support contract this year, you have leverage you didn’t have three years ago. Most engineering teams aren’t using it.
What the pledge actually commits vendors to
CISA’s Secure by Design pledge asks signatories to make measurable progress across a defined set of goals: reducing default passwords, enabling multi-factor authentication as a default rather than an add-on, cutting entire classes of vulnerability (like path traversal or SQL injection) out of products, publishing a vulnerability disclosure policy, increasing the use of memory-safe languages, and — critically for OT buyers — publishing more transparent CVE data with CWE root-cause information.
Notice what’s not in there: a specific timeline with teeth, a third-party audit requirement, or any consequence for a vendor that signs and then doesn’t move the needle. It’s a pledge, not a certification. That’s not a knock on the initiative — getting a critical mass of ICS and IT vendors to publicly commit to anything is progress — but it means the pledge itself does zero work for you unless you make it do work through procurement language.
Why plants keep treating it as a checkbox
Most RFP templates for control system hardware and software were written years before Secure by Design existed, and procurement teams tend to bolt on a line like “vendor must support Secure by Design principles” without defining what that means operationally. Sales engineers are happy to check that box because it costs them nothing to check. A pledge signature satisfies a compliance question on a scorecard; it doesn’t tell you whether the HMI you’re about to put on your plant floor still ships with a hardcoded service account or whether the PLC firmware has ever been through a real fuzzing campaign.
The other reason this gets waved through: manufacturing engineers evaluating a new SCADA or MES-adjacent platform are usually optimizing for uptime, integration effort, and support responsiveness. Security attestation review often falls to whoever’s available, and that’s frequently someone without the ISA/IEC 62443 background needed to know which questions actually separate real hardening from marketing language.
Turning the pledge into RFP language that means something
If you want the attestation to do anything besides look good in a vendor comparison matrix, get specific in the RFP itself. Vague language gets vague answers.
- Ask for evidence, not affirmation. Don’t ask “does your product follow Secure by Design principles.” Ask for the vendor’s current status against each named CISA pledge goal, with dates, and ask what changed in the last product release cycle as a result.
- Require CWE-mapped CVE history. A vendor with a clean CVE list isn’t necessarily secure — it might mean nobody’s looking. A vendor publishing CVEs with root-cause classification (CWE) and remediation timelines is showing you a real vulnerability management process. Ask for the last several disclosures and how they were communicated to customers.
- Specify authentication defaults contractually. No shared default credentials shipped in firmware or install images, MFA available and enabled by default for any remote or engineering-workstation access, and no undocumented service accounts. Put this in the technical requirements section, not the cover letter.
- Ask about the SBOM. A software bill of materials tells you what third-party and open-source components are baked into the HMI or historian you’re buying, which matters enormously when the next widely disclosed library vulnerability hits. Require it be delivered and updated with patches, not produced only on request after an incident.
- Reference IEC 62443 by component, not by brand. If the vendor claims 62443-4-1 (secure development lifecycle) or 62443-4-2 (component security requirements) alignment, ask which certification body issued it, when, and against what product version. A lot of “62443-aligned” language in vendor collateral is self-assessed, not certified — those are very different claims.
Contract clauses worth fighting for
RFP language sets expectations; contract clauses are what you can actually enforce after the PO is signed. A few worth pushing on with your legal and procurement teams:
- Patch SLA with OT-realistic timelines. Vendors will resist tight patch commitments for critical vulnerabilities because OT patching often requires a maintenance window, but you can still get a contractual commitment on time-to-disclosure and time-to-patch-availability, separate from your own deployment schedule.
- Notification obligations, not just disclosure policy. A public vulnerability disclosure policy is good; a contractual requirement that the vendor proactively notify you (not just post a bulletin you have to go find) within a defined window of a vulnerability affecting your specific product version is better.
- Right to audit or right to request evidence. You may not get a full third-party audit clause into every OT vendor contract, but you can often get a right to request supporting evidence for Secure by Design claims — test reports, SBOM updates, pledge progress documentation — on a recurring basis, not just at time of sale.
- No degradation clause on end-of-life. Control systems run long past their software support life. Push for language on what security posture looks like once a product hits end-of-life and whether compensating controls or extended support are available, rather than discovering at year eight that your HMI platform is unsupported and unpatchable.
Acceptance testing: where the claims meet the floor
None of this matters if acceptance testing doesn’t check for it. Factory acceptance testing (FAT) and site acceptance testing (SAT) protocols for control systems traditionally focus on functional performance — does the HMI screen update correctly, does the PLC logic execute as specified. Add a security acceptance section: verify no default credentials are active out of the box, confirm MFA is configurable and functioning for remote access paths, confirm the delivered SBOM matches what’s actually installed, and confirm any ports or protocols enabled by default are ones you actually need running.
This is tedious. It’s also the only point in the relationship where you have real negotiating power — before the check clears and the system is welded into your production line. Once it’s running, “the vendor promised Secure by Design” is not a security control, it’s a line item you can no longer negotiate.
The honest bottom line
Secure by Design is a genuinely useful framework for pushing the ICS vendor market toward better defaults, and CISA deserves credit for getting meaningful vendor participation. But a pledge signature is a starting point for a conversation, not a substitute for one. The plants that will actually reduce OT risk from this initiative are the ones rewriting their RFPs and contract templates now, while they’re at the negotiating table, rather than the ones putting a Secure by Design logo next to the vendor name on a procurement spreadsheet and calling the security review done.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
